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System  analysis  steps 
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1 .  Identify  the  customers  need 

2.  Evaluate  the  proposed  system  for  feasibility 

3.  Perform  economic  and  technical  analysis 

4.  Allocate  function  to  hardware,  software,  people  and 
data  (database) 

5.  Establish  cost  and  schedule  constraints 

6.  Create  a  system  definition 
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1.  Identification  of  need 
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■  Meet  with  customer  and  end-user 

■  Understand  who  the  “real”  customers  are  (and 
uncover  political  agendas) 

■  Understand  the  requirements 

■  Know  the  difference  between  customer  requirements  and 
desirements 

■  Establish  goals 

■  Is  current  technology  adequate  to  meet  goals 

■  What  is  potential  market 

■  How  does  system  integrate  with  existing  constraints 

■  Document  in  a  System  Concept  Document 
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2.  Feasibility  Study 
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■  Related  to  Risk  Analysis  and  Risk  management 

■  Development  risks 

■  Resources  availability 

■  Technology  availability 

■  Security 


■  Evaluate  feasibility  of 

■  Economic  feasibility 

■  Technical  feasibility 

■  Legal  feasibility 

■  Examine  other  alternatives 
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3.  Economic  Analysis 
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■  Perform  Cost/Benefit  analysis 

■  Lots  of  factors  to  look  at 

■  cost  reduction  (CR) 

■  error  reduction  (ER) 

■  increased  flexibility  or  capability  (IF) 

■  increased  speed  (IS) 

■  improvement  in  management  planning  and  control  (MC) 

■  security 
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3.  Technical  analysis 
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■  Assessment  of  the  technical  viability  of  the  system 

■  Is  technology  available? 

■  What  new  materials,  methods  or  processes  are  required? 

■  Tool  available 

■  Models  and  simulations 

■  Probability  theory 

■  Queuing  theory 

■  Control  theory 
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How  to  do  technical  analysis 


■  Build  a  System  Model 

■  Simple  enough  to  understand,  but  as  close  to  reality  as 
possible  (to  yield  valid  results) 

■  Highlight  factors  that  are  relevant  or  important,  and  (with 
discretion)  suppress  those  not  as  important 

■  Include  relevant  factors,  and  should  give  repeatable  results 

■  Small  enough  to  be  timely.  If  too  big,  consider  breaking 
down  into  many  smaller  models 

■  Make  the  model  expandable  and  modifiable.  This  allows 
“tuning”  of  the  model,  and  also  expansion  and  inclusion  of 
changing  requirements 
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4.  Allocate  functions  to... 
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■  Hardware 

■  Software 

■  People 

■  Data  (database) 

■  Other  system  elements 

■  Security 

■  Basically,  an  architectural  model 
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■  Based  on 

■  customer  needs 

■  economic  feasibility 

■  technical  analysis 

■  functional  allocation 

■  Security 

■  Requires  both  management  and  customer  buy-in 

■  Critical  factor  is  typically  time,  not  cost 
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6.  Create  systems  definition 


■  The  “blueprint”  that  guides  the  entire  systems 
development. 

■  Explains  what  each  area  (hardware,  software,  etc)  is 
responsible  for. 

■  Explains  interfaces  between  areas 

■  Forms  the  Systems  Specification ,  which  is  the  basis 
for  future 

■  hardware  engineering 

■  software  engineering 

■  database  engineering 

■  human  engineering 

■  Security  engineering 


Software  Technology  Support  Center  (STSC) 


11 


Modeling  the  system 


S  c 


U.S.AIR  FORCE 


■  It  is  necessary  to  define  the  boundaries  of  the  system. 

■  Typically,  a  graphical  representation  or  model  is  best 
for  “first  cut” 

■  Create  different  models  or  views  of  the  system 
(operational  view,  system  view,  and  technical  view) 

■  DODAF  is  way  to  illustrate  architecture 

■  An  ACD  (architecture  context  diagram)  is  another  a 
high-level  diagram  that  shows  boundaries  between 
the  system  and  its’  environment.  It  lists  external 
interfaces  (informational  boundaries) 
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Linkages  Between  the  Views 
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Systems 

View 

Relates  Capabilities  and 
Characteristics  to  Operational  Requirements 

Specific  Capabilities  Identified 
to  Satisfy  Information- 
Exchange  Levels  and  Other 
Operational  Requirements 


Technical  Criteria  Governing 
Interoperable  Implementation/ 
Procurement  of  the  Selected 
System  Capabilities 


Prescribes  Standards 
and  Conventions 


1:  Technical  Standards  Profile 
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Lifecycle  approach 


User's 

Views 


The  User  Acceptance  Test 
Plan  should  be  used  to  record 
the  users  story  of  the 
systems’  use  and  the  user 
expected  output 
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System  acceptance  Integration 
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Software  Engineering 


Design  Implement  Test 


Plan  for  Maintenance 
Configuration  Management 
Documentation 
Verification  and  Validation 
Software  Quality  Assurance 
Risk  Analysis  &  Risk  Management 

Testing 

Software  Engineering  Project  Management 

Process  Improvement 


Maintain 


Reqts. 

Analysis 
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Lifecycles 

Strengths  and  Weaknesses 


Capability 

Pure 

Waterfall 

Code- 
and  -  Fix 

Spiral 

Modified 

Waterfall 

Prototype 

Poorly  understood 
requirements 

Poor 

Poor 

Excellent 

Fair  to 
Excellent 

Excellent 

Poor  Architecture 

Poor 

Poor 

Excellent 

Fair  to 
Excellent 

Poor  to  Fair 

Highly  Reliable  System 

Excellent 

Poor 

Excellent 

Excellent 

Fair 

System  Growth  Built  in 

Excellent 

Poor  to  Fair 

Excellent 

Excellent 

Excellent 

Risk  Management 

Poor 

Poor 

Excellent 

Fair 

Fair 

Predefined  Schedule 

Fair 

Poor 

Fair 

Fair 

Poor 

Midcourse  Correction 

Poor 

unknown 

Fair 

Fair 

Excellent 

Customer  Visibility 

Poor 

Fair 

Excellent 

Fair 

Excellent 

Management  Visibility 

Fair 

Poor 

Excellent 

Fair  to 
Excellent 

Fair 

Low  Management  and 
developer  skill  level 

Fair 

Excellent 

Poor 

Poor  to  Fair 

Poor 

Low  Overhead 

Poor 

Excellent 

Fair 

Excellent 

Fair 

Rapid  Development  (McConnell,  96) 
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EffortX  Cost 
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Change  Possibility 


Cost  Models  for  Future  Life  Cycle  Processes:  COCOMO  2.0  (Boehm,  1995) 
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Finding  Requirement  Errors 


Requirements 
Review  1  hr 


Design 
2.5  hrs 


Code 
13  hrs 


Deployment 
33  hrs 


Software  Technology  Support  Center  (STSC) 


18 


The  Development  Triangle 
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You  can  control  change  to  only  two  sides  of  a  triangle;  The 
third  side  must  freely  adapt  -  or  else  it’s  not  a  triangle 
anymore. 


Schedule 


Product 

(Functionality  +  Quality) 
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Software  is  both  a  source  of 
amusement  and  engineering 

achievement. 


w 


U.S.AIR  FORCE 


The  Temple  of  Software  Engineering 


If  we  all  work  together, 
look  at  what  we  can  build! 
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GOOD  PROCESS 
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The  Temple  of 
Software  Engineering 


Butjustafew 
stubborn  people 
can  ruin  the  entire 
process! 


POOR  PROCESS 
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More  Information 
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You  can  go  on  the  internet  and  search  for 
more  information  on  the  topics  discussed  and 
/or  check  on  the  links  below: 


www.dau.mil 

www.nps.edu 

www.  a  fit.  edu/about.  cfm 

http  ://www.  u  sab  i  I  ity.  go  v/te  m  p  I  ates/docs/ 
u-test_plan_template.doc 

www.uml.org 
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